home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / gnu / amiga / gccbsrld.lha / README < prev   
Text File  |  1992-06-23  |  4KB  |  101 lines
  1. This diff contains the changes needed to gcc-2.1 (should work for later
  2. versions as well, as most changes can be achieved by clever setting of
  3. provided macros, only very few changes are needed to the non-target
  4. specific source files) to provide base relative code generation. 
  5.  
  6. What does it do? The provided -fpic mode is rather Sun specific, and it
  7. doesn't make much sense on a non-VM system like AmigaDOS (although
  8. providing a message passing multitasking kernel, it doesn't feature virtual
  9. memory and/or protected memory). The thing used here uses the following
  10. technique:
  11.  
  12.  
  13. Normal model:
  14.  
  15. +--------+--------------+
  16. |        |              |   DATA/BSS space are treated like they were directly
  17. |     |              |   accessible from TEXT, absolute addressing can be 
  18. |  TEXT  |  DATA & BSS  |   used, with the linker doing relocation to the 
  19. |        |              |   variable runtime address of the executable.
  20. |     |              |
  21. +--------+--------------+
  22.  
  23.  
  24. Base relative model:
  25.  
  26. +--------+   +--------------+
  27. |        |   |              |  Every access to DATA/BSS from TEXT must go by
  28. |     | B |              |  indirection on a register pointing at the
  29. |  TEXT  |-->|  DATA & BSS  |  DATA/BSS region. This is the so called base
  30. |        |   |              |  relative register (A4 in the AmigaDOS case).
  31. |     |   |              |
  32. +--------+   +--------------+
  33.  
  34.  
  35.  
  36. Advantages to the base relative approach are:
  37. - if working with 16bit offsets into DATA/BSS space, instructions are
  38.   shorter than in absolute addressing mode.
  39. - the shorter instructions are faster as well.
  40. - by having the whole DATA/BSS space accessed only by indirection, it can
  41.   easily be moved or replaced at runtime, providing a way to implement
  42.   fork(2)-like operations even on a non-VM system.
  43. - using this feature of relocation, programs can be made reentrant by just
  44.   giving each new instance of the program its own DATA/BSS region.
  45.  
  46. Limitations of this approach:
  47. - one register is permanently allocated to access DATA/BSS, and is not
  48.   available for other purposes.
  49. - additional support is required in the assembler (to generate special
  50.   relocation information) and in the linker (to handle offsets instead of
  51.   addresses).
  52. - if using addressing like:
  53.     movel a4@(_foo:W),d0
  54.   to access the contents of variable `foo', then there is an upper limit
  55.   of 64K for the size of DATA/BSS.
  56.   There would be a solution to rewrite the above instruction into two
  57.   instructions when compiling in `large data' mode (something similar to
  58.   -fPIC versus -fpic), but I couldn't get gcc to output correct code for
  59.   this situation, so I didn't include the (obviously wrong) code into
  60.   this diff.
  61.  
  62.  
  63. Information to the included diff
  64. --------------------------------
  65. The provided diff is *not* the complete diff to generate an AmigaDOS gcc.
  66. It does however contain the complete current AmigaDOS target-specific
  67. files (in the config/ directory). The additional patches are limited to
  68. providing base relative support. I did this to facilitate incorporating 
  69. these changes into non-Amiga environments, just hope I didn't corrupt
  70. the diffs by editing the other stuff out...
  71.  
  72. If you want to implement this on a different m68k OS, take a look at the
  73. pic/baserel related macros defined in config/amiga.h, use the function
  74. read_only_operand() at the end of config/amiga.c, and try to setup
  75. corresponding changes in your configuration files.
  76.  
  77. If you happen to understand more of gcc's interna than I (which is
  78. easily possible ;-)), please take a look at my kludge in expr.c. The
  79. problem is that internal calls to library functions have to be
  80. qualified as well by ENCODE_SECTION_INFO(), but I didn't know how to
  81. twiddle the existing data into a correct argument to ENCODE_SECTION_INFO(),
  82. so I just inlined my specific action there. I'd like to see a clean
  83. solution, but I'm not able to provide one.
  84.  
  85. I'm very open to suggestions, enhancements, bug reports, etc. I'd be
  86. particularly interested if some kind soul finds out how to get RTL
  87. evalutation to not convert the 
  88.  
  89.     gen_rtx (PLUS, Pmode, pic_offset_table_rtx, orig);
  90.  
  91. into an indirect addressing operand (pic-reg@(orig)), but to leave it
  92. as an addition. The pic-reg@(orig) form is just not suitable for use
  93. on a mc68000 if more than 64K should be addressable.
  94.  
  95.  
  96.  
  97. You can reach me as
  98. <wild@nessie.cs.id.ethz.ch> or <wild@amiga.physik.unizh.ch>
  99.  
  100. -Markus Wild
  101.